4장. 잘 만들었는지 채점하기 (평가)

출처: 『AI 엔지니어링』(Chip Huyen 지음) | 원서: AI Engineering (O'Reilly) — 본 입문판은 PDF 원문(4장)에서 직접 풀어 썼다.

코드는 분위기만 — Python·API 같은 말은 몰라도 됩니다. 표의 '비유'와 '위험'만 봐도 충분해요.

0. 이 장의 새 단어

0장에 없는 말 3개만 미리 풀어 둔다.

본문에서 막히면 여기로 돌아오면 된다.

평가 주도 개발(evaluation-driven development)

한 문장 뜻 — 앱을 만들기 전에 "어떻게 채점할지"부터 먼저 정해 놓는 방식.

일상비유 — 시험 보기 전에 채점 기준표를 먼저 짜는 것. 기준 없이 답안만 쌓으면 잘했는지 못했는지 알 수가 없다.

한 줄 예 —

# 만들기 전에 "무엇을 합격으로 볼지" 먼저 못 박음
# 여러 값을 이름표가 붙은 구조로 묶어 전달합니다.
기준 = {"사실 맞아야": True, "3초 안에": True}

사실 일관성(factual consistency)

한 문장 뜻 — 모델 답이 주어진 자료나 알려진 사실과 어긋나지 않는 정도.

일상비유 — 원고와 대조해 가며 틀린 곳 잡는 교정. 그럴듯해 보여도 원본과 안 맞으면 틀린 것이다.

한 줄 예 —

# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 답이 자료와 맞는지 대조
일치 = check(답, 원본_자료)  # 안 맞으면 사실 비일관

데이터 오염(data contamination)

한 문장 뜻 — 시험 문제(벤치마크)를 모델이 학습 때 미리 봐 버려서 점수가 부풀려지는 일.

일상비유 — 시험지를 미리 외워 온 학생. 점수는 100점인데 진짜 실력은 모른다.

한 줄 예 —

# 학습 데이터 안에 시험 문제가 섞여 있었음
# 조건을 확인해서 상황에 맞는 처리 경로를 고릅니다.
if 시험문제 in 학습데이터: 점수_못_믿음 = True

(귀납 도입) 이런 적 있죠?

"주말에 만든 챗봇 데모, 멋지게 돌아서 회사에 깔았다."

"1년이 지났다. 사람들은 잘 쓰는 것 같다. 그런데… 이게 답을 제대로 하고 있는 건가? 아무도 모른다."

실제로 저자가 만난 중고차 가격 예측 모델 이야기다.

배포한 지 1년이 됐는데 예측이 맞는지 만든 사람도 알 수 없었다.

# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 깔긴 깔았는데, 맞는지 확인할 방법이 없음
deploy(model)   # 잘 돌아가는 것 "같다"
# 정확도? → ??? (채점표가 없음)

저자는 묻는다.

"배포 안 된 앱과, 배포는 됐는데 잘 도는지 모르는 앱. 둘 중 뭐가 더 나쁠까?"

대부분 후자가 더 나쁘다고 답한다.

고칠 수도 없고, 멈추기도 무서운 앱이 되기 때문이다.

그래서 저자는 단언한다.

채점(평가)이야말로 AI 도입의 가장 큰 걸림돌이자 기회다.

만드는 건 쉬워졌다.

잘 만들었는지 채점하는 것이 진짜 어렵다.

이 장에서 딱 4가지만

① 무엇으로 채점하나 — 도메인 실력·생성 품질·지시 따르기·비용/속도, 이 4가지 기준으로 잰다. ② 사실을 지어내는지 어떻게 잡나 — 자료와 대조(국소)하거나 세상 지식과 대조(전역)한다. ③ 공개 시험 점수(벤치마크)를 믿어도 되나 — 출발점일 뿐. 시험지가 새면(데이터 오염) 점수는 거짓말이 된다. ④ 내 앱 전용 채점 라인 어떻게 짜나 — 부품별로 따로 채점하고, 채점 기준표를 먼저 만든다.

학습 목표

• AI 앱을 채점하는 네 가지 기준을 설명한다.
• 사실을 지어내는지(환각) 잡는 방법을 구분한다.
• 공개 벤치마크를 왜 그대로 믿으면 안 되는지 설명한다.
• 내 앱 전용 채점 라인을 만드는 3단계를 설명한다.

개념 1 — 네 가지 채점 기준

새로 산 자동차를 평가한다고 해 보자.

"빠른가"만 보지 않는다.

빠른지, 안전한지, 시킨 대로 도는지, 기름값은 싼지를 같이 본다.

AI 앱도 똑같다. 한 가지로 채점하면 반쪽짜리다.

한 문장 정의 — AI 앱은 도메인 실력·생성 품질·지시 따르기·비용/속도, 이 네 기준으로 채점한다.

단순 규칙: 앱을 만들기 전에 이 네 기준을 먼저 적어 둔다. (= 평가 주도 개발)

예시 ① (worked — 완성 예) 법률 계약서 요약 앱.

• 도메인 실력 = 계약서를 잘 이해하나
• 생성 품질 = 요약이 원문과 안 어긋나나
• 지시 따르기 = "5줄 이내" 같은 형식을 지켰나
• 비용/속도 = 한 건에 얼마, 몇 초

예시 ② (부분 완성 — 빈칸 채우기) 번역 앱.

• 도메인 실력 = (빈칸: 두 언어를 아나)
• 비용/속도 = (빈칸: 한 문장당 초, 원)

예시 ③ (독립 적용) 고객 지원 챗봇을 네 기준으로 직접 적어 보라.

한 걸음 더 ▸ (지금 몰라도 됨)

"채점하기 쉬운 것만 만들면 안 되나?" 그게 함정이다. 가로등 아래에서만 열쇠를 찾는 격이다. 밝아서 쉽지만, 거기 열쇠가 없을 수도 있다. 채점이 어렵다는 이유로 진짜 좋은 아이디어를 놓칠 수 있다는 뜻이다.

한 걸음 더 ▸ 비용/속도는 어떻게 재나 (지금 몰라도 됨)

속도는 "첫 글자가 나오기까지 걸린 시간" 같은 걸로 잰다. 모델은 글자를 하나씩 뱉어서, 답이 길수록 느려진다. 비용은 보통 글자(토큰) 수만큼 매겨진다. 남이 빌려주는 모델(API)은 많이 써도 글자당 값이 비슷하지만, 직접 굴리면 많이 쓸수록 글자당 값이 싸진다. 품질·속도·비용을 한꺼번에 맞추는 줄다리기를 파레토 최적화라 부른다. 지금은 "빠르고 싼지도 같이 본다"만 알면 된다.

개념 2 — 도메인 실력: 잘 달려도 기름 먹으면 꽝

코드를 짜는 앱을 만든다.

모델이 코드를 짰다. 돌아간다. 합격?

아직 아니다.

그 코드가 1분씩 걸리거나 메모리를 다 잡아먹으면 아무도 안 쓴다.

한 문장 정의 — 도메인 실력은 모델이 그 분야 일(코딩·번역·수학)을 할 줄 아는지이며, 코딩은 정확성·효율성·가독성을 함께 본다.

단순 규칙: 코딩은 "맞나"에 "빠른가"와 "읽히나"를 꼭 붙여서 채점한다.

코딩이 아닌 분야는 주로 객관식으로 채점한다.

객관식이 왜 인기일까.

만들기 쉽고, 채점이 자동이고, 4지선다면 찍어도 25%라 비교 기준이 분명하다.

예시 ① (worked) 객관식 채점.

# `정답`에 중간 결과를 담아 다음 줄에서 재사용합니다.
정답 = "C"
# `모델_답`에 중간 결과를 담아 다음 줄에서 재사용합니다.
모델_답 = "A"
맞음 = (모델_답 == 정답)   # False, 자동으로 채점 끝

예시 ② (잘못된 예 vs 올바른 예) 객관식의 함정.

• 잘못된 예: 글쓰기·요약 실력을 객관식으로 잰다. → 객관식은 "고르기"지 "만들기"가 아니라 안 맞는다.
• 올바른 예: 지식·추론은 객관식으로, 요약·번역은 생성 품질(개념 3)로 잰다.

예시 ③ (미니 시나리오) 같은 문제인데 공백 한 칸, "선택지:" 한 줄을 더 넣었더니 모델 답이 바뀌었다.

이것이 객관식의 약점이다. 살짝만 바꿔도 점수가 흔들린다.

한 걸음 더 ▸ (지금 몰라도 됨)

왜 답이 흔들릴까. 모델은 글자 모양에 민감하기 때문이다. 이 "프롬프트 민감도"를 길들이는 법은 더 깊은 주제다. 지금은 "객관식 점수는 조금 흔들린다"만 알면 된다.

개념 3 — 생성 품질: 헛소리(환각)를 잡아라

모델이 "관련 판례가 있습니다"라며 술술 말한다.

말투가 너무 자신만만하다.

그런데 그 판례, 실제로는 없다. 지어낸 거다.

이게 환각이고, 이걸 잡는 게 사실 일관성 채점이다.

대조할 기준이 두 가지다.

한 문장 정의 — 사실 일관성은 답이 주어진 자료(국소적)나 알려진 지식(전역적)과 어긋나지 않는 정도다.

단순 규칙: 답과 대조할 "자료"가 손에 있으면 채점이 훨씬 쉽다.

예시 ① (worked) 국소적 — 자료가 있는 경우.

# `자료`에 중간 결과를 담아 다음 줄에서 재사용합니다.
자료 = "하늘은 보라색이다"
# `답`에 중간 결과를 담아 다음 줄에서 재사용합니다.
답 = "하늘은 파랗다"
# 자료와 어긋남 → 이 자료 기준으로는 '사실 비일관'

예시 ② (잘못된 예 vs 올바른 예) 전역적 — 자료가 없는 경우.

• 잘못된 예: "증거를 못 찾았으니 연관성이 없다"고 단정. → 증거 부재의 오류다.
• 올바른 예: 믿을 만한 출처를 먼저 찾고, 그 출처에 비춰 판단한다.

예시 ③ (미니 시나리오) 모델이 헛소리를 잘 하는 두 자리.

• 잘 안 알려진 주제 (국제 대회보다 어느 나라 지역 대회 질문에서 더 지어냄)
• 없는 정보를 묻는 질문 ("X가 Y에 대해 뭐랬어?" — X가 말한 적 없으면 더 지어냄)

헛소리 잡는 도구 3종

• 자체 검증(SelfCheckGPT) — 같은 걸 N번 더 물어본다. 답이 서로 안 맞으면 처음 답이 헛소리일 확률이 높다.
• SAFE — 답을 문장으로 쪼개고, 각 문장을 검색 엔진으로 대조한다. (구글 딥마인드)
• NLI(텍스트 함의) — '메리는 모든 과일을 좋아한다'가 전제일 때: '사과를 좋아한다'=함의, '오렌지를 싫어한다'=모순, '닭고기를 좋아한다'=중립. 함의면 사실 일치, 모순이면 불일치다.

비용 요령 (잘못된 예 vs 올바른 예)

• 잘못된 예: 비싼 AI 평가자 하나로 데이터 100%를 다 채점한다. → 돈이 너무 든다.
• 올바른 예: 싸고 빠른 NLI로 100%를 훑고, 비싼 AI 평가자는 1%만 정밀 채점한다.

안전성도 함께 본다

헛소리만 위험한 게 아니다. 해로운 답도 막아야 한다.

욕설, 위험한 지침("은행 터는 법"), 혐오 발언, 폭력 묘사, 고정관념, 정치·종교 편향 등이다.

작고 빠른 전용 분류기(혐오 발언 감지 모델 등)로 싸게 거를 수 있다.

한 걸음 더 ▸ (지금 몰라도 됨)

검색해서 자료를 붙여 주면 헛소리가 준다. 이 "자료 붙이기" 방식이 따로 있다(RAG, 0장 참고). RAG가 잘 도는지도 결국 이 사실 일관성으로 채점한다. 지금은 "자료와 대조한다"만 기억하면 된다.

개념 4 — 지시 따르기: 실력 있어도 말 안 들으면 꽝

트윗 감정을 "긍정/부정/중립"으로 답하라고 시켰다.

모델은 감정을 잘 알아챈다.

그런데 "행복함", "화남"이라고 답한다.

실력은 있는데 시킨 형식을 안 따른 것이다. 이게 지시 따르기 문제다.

한 문장 정의 — 지시 따르기는 모델이 시킨 형식·규칙(보기·JSON·길이·말투)을 지키는 능력이며, 실력과는 별개다.

단순 규칙: 형식 지시는 프로그램으로 자동 채점, 내용 지시는 예/아니오 질문으로 채점.

예시 ① (worked) 형식 지시 — 자동 채점 (IFEval 방식).

# "ephemeral 단어를 넣어 문장 써" → 들어갔는지 프로그램이 확인
# `통과`에 중간 결과를 담아 다음 줄에서 재사용합니다.
통과 = "ephemeral" in 답

예시 ② (부분 완성) 내용 지시 — 예/아니오 채점 (INFOBench 방식).

"호텔 리뷰용 설문지를 만들어"라는 지시는 이렇게 쪼개 채점한다.

• 설문지가 맞나? (예/아니오)
• 호텔 손님용인가? (예/아니오)
• (빈칸: 리뷰 작성에 ___ 되나?)

셋 중 둘을 충족하면 점수는 2/3이다.

예시 ③ (미니 시나리오 — 역할 연기) 모델에게 특정 캐릭터를 연기시킨다.

• 말투 — 그 캐릭터처럼 말하나
• 지식 — 그 캐릭터가 알 법한 것만 말하나 (게임 NPC가 스포일러를 흘리면 실패)

한 걸음 더 ▸ (지금 몰라도 됨)

답이 나쁠 때, 모델이 못한 건지 내 지시가 나빴던 건지 구분이 어렵다. 지시를 잘 쓰는 법은 더 깊은 주제다. 지금은 "실력과 말 듣기는 따로 채점"만 기억하면 된다.

개념 5 — 공개 시험 점수(벤치마크)를 그대로 믿지 마라

모델 고를 때 공개 순위표(리더보드)를 본다.

"1위 모델 = 내 앱에도 최고"일까?

아니다. 두 가지 함정이 있다.

한 문장 정의 — 공개 벤치마크는 나쁜 모델을 거르는 출발점일 뿐, 시험지 유출(데이터 오염)과 치우친 집계 때문에 그대로 믿으면 안 된다.

단순 규칙: 공개 점수로 후보 몇 개만 추리고, 최종 선택은 내 앱 전용 채점(개념 6)으로 한다.

예시 ① (worked — 데이터 오염 증명) 한 연구자가 시험 문제만으로 작은 모델을 학습시켰다.

그 모델은 여러 시험에서 거의 만점을 받았다. 실제로는 아무 쓸모가 없는데도.

# 시험 문제만 외운 모델 → 시험은 만점, 실전은 빵점
# 모델을 조금 더 가르치거나 학습 설정을 준비합니다.
model.train(벤치마크_정답들)
model.run(같은_벤치마크)  # 만점 (당연히)

예시 ② (잘못된 예 vs 올바른 예) 점수 다루기.

• 잘못된 예: 리더보드 점수를 그대로 믿고 바로 배포한다.
• 올바른 예: 시험지가 샜는지 먼저 의심한다. (n-gram 중복: 학습 데이터에 접근되면 정확하지만 비쌈 / 퍼플렉시티: 거칠지만 쌈)

예시 ③ (미니 시나리오 — 집계 편향) 순위표가 비슷비슷한 추론 시험만 잔뜩 평균냈다.

그러면 추론 잘하는 모델이 과하게 높게 나온다. 정작 "사실 잘 말하나"는 거의 안 반영된다.

한 걸음 더 ▸ (지금 몰라도 됨)

모델이 좋아질수록 기존 시험은 너무 쉬워져 변별력을 잃는다(벤치마크 포화). 그래서 시험은 계속 더 어려워진다. 지금은 "공개 점수는 출발점일 뿐"만 기억하면 된다.

개념 6 — 내 앱 전용 채점 라인 3단계

공개 점수를 못 믿으니, 내 앱 전용 채점 라인을 직접 짠다.

요리에 비유하면 손님에게 내기 전 검수 라인을 까는 것이다.

한 문장 정의 — 자체 평가 파이프라인은 ① 부품별로 따로 채점하고 ② 채점 기준표를 먼저 만들고 ③ 기준마다 맞는 방법과 데이터를 정하는 3단계다.

단순 규칙: 채점 기준표 만들기가 절반이다. "좋다"가 뭔지 못 박는 게 제일 어렵다.

예시 ① (worked — 1단계) 이력서에서 현재 직장 뽑는 앱은 두 공정이다.

1. PDF → 글자 뽑기
2. 글자 → 현재 직장 찾기

따로 채점해야 어디서 틀렸는지 안다.

# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
점수1 = 비교(뽑은_글자, 진짜_글자)   # 1공정
점수2 = 정확도(찾은_직장)            # 2공정

예시 ② (부분 완성 — 2단계) "정확한 답 = 좋은 답"이 아니다.

직무 평가 앱이 "당신은 이 자리에 전혀 안 맞아요"라고 답했다.

정확할 수 있다. 하지만 좋은 답은 아니다.

좋은 답 = (빈칸: 부족한 점을 설명하고, ___ 방법까지 알려주는 답).

예시 ③ (독립 적용 — 채점 점수와 사업 연결) 사실 일관성 점수를 사업 숫자로 바꿔 본다.

• 사실 일관성 80% → 고객 문의 30% 자동 처리 가능
• 사실 일관성 90% → 50% 가능
• 사실 일관성 98% → 90% 가능

이렇게 연결하면 "점수를 올릴 가치가 있나"를 결정하기 쉬워진다.

채점 표본은 몇 개면 될까

오픈AI가 내놓은 거친 기준이다.

작은 차이를 가리려면 표본이 확 늘어난다.

한 걸음 더 ▸ (지금 몰라도 됨)

전체 평균만 보면 함정에 빠진다. 데이터를 쪼개(슬라이스) 봐야 한다. 전체로는 A가 좋아 보여도, 쪼개 보면 모든 조각에서 B가 더 좋은 황당한 일(심슨의 역설)이 있다. 또 AI 평가자는 온도를 0으로 두어 같은 입력에 같은 점수가 나오게 한다. 지금은 "쪼개서도 본다"만 알면 된다.

정리

AI 앱 채점은 네 기준(도메인·생성·지시·비용)으로 시작한다.

헛소리는 자료(국소)나 세상 지식(전역)과 대조해 잡고, 싼 도구로 훑고 비싼 도구로 1%만 정밀 채점한다.

공개 점수는 출발점일 뿐 — 시험지가 새면 거짓말이 되니, 후보만 추리고 최종은 내 앱 전용 채점 라인(부품별 검사 → 기준표 → 방법/데이터)으로 정한다.

더 해보기

• Hugging Face 오픈 LLM 리더보드 — 공개 순위표가 실제로 어떻게 생겼는지 한 번 보라. (생존 확인 2026-05-21)

다음 5장에서는 모델에게 말을 더 잘 거는 법(프롬프트 엔지니어링)을 본다. (지금 몰라도 됩니다 — 5장에서 풀려요.)

연습문제

1. 설명. 잘 만들었는지 채점하기의 핵심을 처음 듣는 사람에게 한 문장으로 설명하라.
2. 구분. 두 개념(벤치마크, 앱 전용 평가)을 실제 예시 하나로 구분하라.
3. 적용. 내 프로젝트나 학습 노트에서 이 장의 개념을 적용해 작게 개선할 지점을 하나 고르라.

부록 A. 쉬운 용어 사전

부록 B. 헷갈리는 개념 비교표

부록 C. 더 읽을 자료

• 이 장의 더 해보기 섹션 — 이미 모아 둔 공식 문서나 실습 링크가 있으면 여기서 먼저 확인한다.
• 같은 책의 0장 한눈에 보기 — 용어가 막히면 0장의 용어집과 개념 척추로 돌아간다.
• 원본 딥다이브판 같은 장 — 입문판을 읽고 큰 흐름이 잡힌 뒤 세부 논리를 더 깊게 확인한다.
• 이 장의 flashcards.json — 읽은 직후 질문만 보고 답을 떠올리는 회상 연습에 쓴다.

부록 D. 연습문제 풀이

1. 설명 예시. 잘 만들었는지 채점하기는 거대 모델을 제품에 넣을 때 어떤 선택을 하고 어떻게 확인할지 판단하게 해 주는 장이다. 중요한 것은 용어를 외우는 것이 아니라, 이 개념이 어떤 입력·부품·결정에 영향을 주는지 말로 풀어 보는 것이다.
2. 구분 예시. 두 개념(벤치마크, 앱 전용 평가)의 차이는 이렇게 잡으면 된다. 벤치마크는 공개 시험, 앱 전용 평가는 내 제품의 실제 실패를 본다. 실제 사례를 볼 때는 목적, 입력, 실패했을 때의 증상을 따로 적어 보면 헷갈리지 않는다.
3. 적용 예시. 가장 작은 개선부터 고른다. 예를 들어 이름을 더 분명히 하거나, 평가 기준을 한 줄 추가하거나, 직접 알 필요 없는 내부 정보를 감추는 식으로 시작한다. 한 번에 크게 갈아엎는 것보다 작은 변경 하나를 확인하며 진행하는 쪽이 입문 단계에 맞다.